In contemporary computing, computer application programs and other code may be downloaded and installed from the Internet. This leads to potential problems in that untrusted sources such as the Internet often provide code that is intentionally malicious or otherwise capable of harming or providing unauthorized access to important data. However, because there are many situations in which computer users benefit from the ability to download code and execute code without prompting, completely preventing downloading is not a practical solution to this problem.
One solution to this problem is referred to as sandboxing, a generic security term that applies to any environment that reduces the privileges under which an application runs. It is particularly valuable to sandbox applications downloaded from the Internet, as they tend to come from unknown or untrusted sources.
Some environments, such as one based on Microsoft Corporation's Windows® Presentation Foundation and .NET technologies, attempt to solve the problems of running untrusted code via a sandbox-model that limits what the untrusted code has permission to do. For example, the underlying platform can require that its callers have specific permissions, and while code can request the permissions it needs for the execution, the runtime will only grant permission based on policy that evaluates how much the code is trusted. Such permissions include things like the ability to access files and databases, connect to the Internet, interact with the user via a user interface, call into unmanaged code, and so forth. One policy-based solution is to prompt the user when code requests such permissions, however this solution is not very desirable because a typical user is often not equipped to make a correct security decision when prompted.
As can be readily appreciated, writing secure code for platforms that enable applications to be downloaded and installed from the Internet without prompting is an extremely difficult problem. This is because the platform itself needs to have elevated privileges to properly operate. Security flaws can exist if any part of the platform code is written such that it inadvertently exposes an internal way to run untrusted code with elevated permissions/privileges, (that is, allow the untrusted code to do something beyond what would otherwise be allowed via its reduced permission set), because this would allow the untrusted code to perform unsafe operations. By way of example, the platform code needs to be able to call unmanaged code for operating system services, such as to render text on a window, while untrusted code is not allowed to do so; however if the platform code is inadvertently written such that the untrusted code can call unmanaged code via a call to a internal method of the platform code, a security flaw exists.
One solution that increases the likelihood that platform code is securely written is to allow the developer to mark (e.g., using metadata) any part of the platform code that requires elevated permissions to run, or mark code that controls whether elevated permissions can be run. In general, the metadata indicates that the marked set of platform code is “critical” code that performs a dangerous operation. Security teams and static code analysis tools (e.g., FxCop is one such code analysis tool that checks .NET managed code assemblies) then recognize the metadata, whereby platform features can be developed so that the likelihood of platform code running with elevated privileges being exposed to untrusted code is dramatically reduced.
However, while highly valuable, the marking of such code and data as critical results in a complex code-review process that burdens a security team with many critical methods that need to be code reviewed.